Bijgestelde reactie op BIT-advies over Operatie BRP (naar aanleiding van 
Algemeen Overleg op 26 november 2015) 

d.d. 11 januari 2016 


1. Inleiding 

Het Bureau ICT-Toetsing (BIT) heeft in zijn pilot periode een toets uitgevoerd op Operatie BRP 
(oBRP). Deze toets heeft geleid tot een brief van 18 september 2015 waarin het BIT zijn advies aan 
u heeft opgenomen. In de stuurgroepvergadering Operatie BRP van 24 september 2015 heeft het 
Hoofd BIT het advies toegelicht en besproken met de leden van de stuurgroep. Naar aanleiding van 
deze bespreking hebt u van Hoofd BIT een aanvullende brief met verduidelijking op een tweetal 
punten ontvangen. 

Op 23 oktober 2015 heb ik een reactie op het BIT-advies opgesteld. De minister van BZK heeft die 
als bijlage bij zijn periodieke voortgangsbrief gevoegd. De briefen bijlagen zijn op 26 november 
2015 in een Algemeen Overleg (AO) aan de orde geweest. In dat AO zegde de minister toe om de 
Kamer in januari 2016 een brief te sturen over de opmerkingen van het BIT. Enkele kamerleden 
vroegen in het AO om bij de aanbevelingen/adviezen van het BIT aan te geven welke concrete 
maatregelen worden getroffen. Deze notitie bevat per aanbeveling van het BIT de gevraagde 
beschrijving van de concrete maatregelen. In de bijlage is een korte analyse van de door het BIT 
benoemde risico's opgenomen. 


2. Hoofdconclusie van BIT 1 

Het BIT heeft onderzocht of het programma in de huidige vorm tot een goed resultaat kan komen. 
De hoofdconclusie van het BIT luidt als volgt: 

’We zijn van mening dat het programma succesvol afgerond kan worden op basis van de huidige 
besturing en aanpak, mits een aantal risico's en onzekerheden nadrukkelijker gemanaged worden. 
Hiervoor adviseren we een aantal concrete maatregelen." 

De besturing en de aanpak van het programma zijn naar mijn mening de cruciale randvoorwaarden 
om de BRP op een gecontroleerde wijze te realiseren. Ik ervaar deze hoofdconclusie van het BIT 
dan ook als een duidelijke steun in de rug voor de koers die de stuurgroep sinds oktober 2013 
vaart. In het verlengde daarvan merk ik op dat het BIT geen kanttekeningen plaatst bij het hart 
van het programma, het ontwikkelproject. Ook dat ervaar ik als positief. 


3. Aanbevelingen BIT 

Het BIT doet een viertal aanbevelingen om de door het BIT benoemde risico's en onzekerheden te 

beheersen. Het BIT werkt iedere aanbeveling uit in een aantal maatregelen. Hieronder geef ik in 

mijn reactie op de aanbevelingen aan welke concrete maatregelen ik neem. 

Aanbeveling BIT 1 

Zorg ervoor dat het programma de nieuwe BRP zonder verdere verstoringen kan afmaken. 

Werk aan vertrouwen in de oBRP door een ongestoorde afbouw van een basisversie: 

a. Spreek met de Tweede Kamer af dat nieuwe wijzigingen pas worden doorgevoerd nadat het 
huidige programma oBRP is afgerond en alle GBA-aansluitingen zijn uitgefaseerd. Informeer de 
Tweede Kamer bij toekomstige wijzigingen vooraf goed over de consequenties. 

b. Laat BRP-versie 3.1 formeel door de beheerorganisatie accepteren. 

c. Implementeer BRP-versie 3.7, waarin ook L03.9 en het Buitenlands Persoonsnummer zijn 
opgenomen, op de kortst mogelijke termijn zodat de centrale database van de huidige GBA 
volledig wordt vervangen door die van de BRP. 

d. Overweeg om de functionaliteit 'fiatteringsknop'in BRP-versie 4.3 terug te draaien. 

Opvolging van aanbeveling 1: 


1 Voor de goede orde herhaal ik in deze paragraaf het in de eerdere reactie gestelde over de 
hoofdconclusie van het BIT. 
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Aanbeveling (a) voer ik uit, waarbij bij nieuwe voorstellen tot wijzigingen vanuit de 
politieke omgeving opnieuw weging plaatsvindt tussen wenselijkheid en "impact" voor 
het programma. Aanbeveling (b) voer ik ook uit en aanbeveling (c) neem ik vanuit het 
oogpunt van risicobeheersing gedeeltelijk over. Aanbeveling (d) neem ik niet over. 

Toelichting ad al: 

De aanbeveling om nieuwe wijzigingen pas door te voeren nadat het programma is afgerond en 
alle GBA-aansluitingen zijn uitgefaseerd krijgt invulling door wijzigingen uit de omgeving te 
realiseren nadat de nieuwe BRP is ingevoerd, in de BRP-release 1.1. Bij wijzigingen vanuit de 
politieke omgeving vindt weging tussen wenselijkheid en "impact" voor het programma plaats, de 
Kamer wordt daarover geïnformeerd. 

In hoofdstuk 4 van deze notitie ga ik nader in op de grote invloed van wijzigingen op het 
ontwikkeltraject. 

Toelichting ad bl: 

De aanbeveling om BOP-stap 3.1 (mutatieleveringen) formeel door RvIG te laten accepteren past 
niet in het gehanteerde uitgangspunt dat formele acceptatie alleen plaatsvindt voor releases die in 
productie gaan. Deze aanbeveling wordt daarom als volgt opgevolgd. Vanaf BOP-stap 2.2 
doorlopen alle opleveringen vanuit het programma een toetsproces waarin programma en RvIG 
toetsen in hoeverre de opgeleverde systeemdelen voldoen aan de functionele eisen en aan de "non 
functional requirements" (NFR's). Daarbij is formeel geen sprake van acceptatie en vrijgave, dat is 
alleen aan de orde voor die releases die daadwerkelijk in productie gaan. Wel ontstaat op deze 
manier na iedere release, dus vroegtijdig, een beeld van de kwaliteit van de opgeleverde producten 
in relatie tot de functionele en niet-functionele eisen en in het verlengde daarvan een antwoord op 
de vraag of RvIG de release daadwerkelijk in beheer zou kunnen nemen. Het programma en RvIG 
bezien per release of aanscherping van het toetsproces aan de orde is. Over de uitkomst van het 
acceptatieproces vindt formele rapportage aan de stuurgroep plaats. Deze werkwijze stelt de 
stuurgroep in staat om bij te sturen als de kwaliteit van de opgeleverde producten te wensen over 
zou laten. 

Toelichting ad cl: 

De aanbeveling om met BOP-stap 3.7 (Leveringen) zo snel als mogelijk in productie te gaan 
(inclusief de vulling van de database) neemt de stuurgroep vanuit het oogpunt van 
risicobeheersing niet onverkort over. Dat heeft als reden dat de stuurgroep wil voorkomen dat de 
leveringsfunctionaliteiten al in productie zijn terwijl het detailontwerp voor de 
bijhoudingsfunctionaliteiten nog niet is afgerond. Dat zou namelijk het risico met zich meebrengen 
dat het detailontwerp voor bijhouding aanleiding geeft tot (ingrijpende) aanpassingen in de 
leveringsfunctionaliteiten (inclusief de migratievoorzieningen) die in productie zijn, wat weer 
vervelende gevolgen voor afnemers kan hebben. De stuurgroep heeft in dit kader (vanuit het 
perspectief van risicobeheersing) besloten dat de leveringsfunctionaliteiten pas in productie gaan 
wanneer voor het onderdeel Bijhouden alle ontwerpen (inclusief het aantonen van de werking 
daarvan in "Proof of Concepts") zijn afgerond, alle voor de bijhoudingsfunctionaliteit noodzakelijke 
componenten zijn opgeleverd voor acceptatie en er tijdens de oplevering door het ontwikkelteam 
daarvan geen blokkerende bevindingen zijn geconstateerd. 

Toelichting ad d): 

Waar het gaat om de vierde suggestie is de "fiatteringsknop" nodig om de wet-en regelgeving uit 
te voeren. Daardoor is het feitelijk niet mogelijk deze functionaliteit "terug te draaien". Het 
programma heeft wel een aanzienlijke versimpeling van het oorspronkelijke ontwerp van de 
fiatteringsknop doorgevoerd, die past binnen de wettelijke en beleidsmatige kaders. 

Aanbeveling BIT 2 

Wees transparant over de planning, inclusief de onzekerheden. 

Maak een nieuwe en complete planning voor de ontwikkel- en implementatiefase met een lijst van 
op te leveren (deel)producten. Wees duidelijk over de onzekerheden en werk waar nodig met 
bandbreedtes. Pas de business case aan op basis van de bijgestelde planning en laat daarmee de 
toegevoegde waarde van het programma zien. Bewaak en rapporteer de voortgang op basis van de 
productenlijst en de onzekerheden. Dit bevordert de transparantie over de voortgang van het 
programma naar alle belanghebbenden. 


2 



Opvolging van aanbeveling 2: 

Deze aanbeveling voer ik uit: de bedoelde planning wordt opgesteld en bewaakt en de 
business case wordt gevalideerd. 

Toelichting: 

Begin 2015 heeft de stuurgroep opdracht gegeven per eind 2015 een integrale planning op te 
stellen voor het resterende ontwikkeltraject (inclusief de eerder benoemde wijzigingen en inclusief 
de onzekerheden), de in productie name door RvIG en de transitieperiode waarin afnemers en 
gemeenten op de BRP aansluiten. 

Het programma heeft ten behoeve van de planning voor het resterende ontwikkeltraject per 
(driemaandelijkse) release in kaart gebracht welke functionaliteiten en producten onderdeel van 
die release uitmaken (lijst werkpakketten). Het programma zal de maandelijkse 
voortgangsrapportage aan de stuurgroep op de lijst met werkpakketten en de begroting per 
release baseren. 

Het bijstellen van de business case is in gang gezet. Het bijstellen van de kosten gebeurt op basis 
van de (bijgestelde) begroting van het programma, die weer is gebaseerd op de integrale planning. 
Tevens iaat het programma valideren of de business case op het vlak van de baten bijstelling 
behoeft. 

Aanbeveling BIT 3 

Betrek de beheerorganisatie intensief zodat kennis wordt opgebouwd en de acceptatie wordt 
vergroot. 

Zorg voor een gestructureerd acceptatieproces zodat duidelijk is onder welke condities de BRP 
wordt geaccepteerd: 

a) Laat de RvIG een lijst van duidelijke acceptatiecriteria opstellen voor de overdracht naar 
beheer en laat deze door de stuurgroep vaststellen. 

b) Laat de RvIG op korte termijn de oplossing toetsen op beheerbaarheid en 
toekomstvastheid en hierover rapporteren aan de Stuurgroep. 

c) Laat de RvIG op korte termijn deelnemen in het ontwikkeltraject, bijvoorbeeld door het 
maken van de beheerdocumentatie. 

d) Laat de beheerorganisatie meewerken om wijzigingen te realiseren onder 
verantwoordelijkheid van het programma. 

Opvolging van aanbeveling 3: 

Aanbevelingen a) en b) voer ik uit door het vaststellen van de acceptatiecriteria voor de 
in beheer name en het toetsen op beheerbaarheid en toekomstvastheid door RvIG 
binnen het formele acceptatieproces. 

Aanbevelingen c) en d) voer ik gedeeltelijk uit omdat daaraan voor RvIG begrenzingen 
verbonden zijn. 

Toelichting ad a): 

De acceptatiecriteria vallen uiteen in twee onderdelen: 

• functionele eisen, die aangeven wat de gewenste functionele werking van de BRP en de 
migratievoorzieningen is; 

• niet-functionele eisen, die bijvoorbeeld betrekking hebben op de productiestabiliteit, de 
performance, documentatie, codekwaliteit, etc. 

De functionele eisen liggen vast in de wet- en regelgeving, beleidsinterpretaties daarvan en in 
beleidsdocumenten. Deze zijn integraal in kaart gebracht. RvIG is formeel verantwoordelijk voor 
het vaststellen van de niet-functionele eisen. RvIG heeft deze eisen inmiddels vastgesteld en heeft 
de stuurgroep daarover geïnformeerd. 

Toelichting ad b): 

RvIG zal de opgeleverde voorzieningen toetsen op beheerbaarheid en toekomstvastheid. Dat krijgt 
concreet vorm door participatie van RvIG in zowel het acceptatieproces voor iedere release als in 
het schaduwdraaien (ik licht dit nader toe in mijn reactie op risico/onzekerheid D, in de bijlage bij 
deze notitie). De niet-functionele eisen vormen de basis voor de toetsen. 
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Toelichting ad c en dl: 

Participatie van RvIG in het ontwikkeltraject is gerealiseerd, medewerkers van RvIG stellen 
bijvoorbeeld de beheerhandleidingen op. Ook is RvIG intensief betrokken bij de ontwikkeling van 
de beheerfunctionaliteit en de voorbereiding van de acceptatietesten en de transitieperiode. 

Wel zijn de mogelijkheden voor RvIG om in het ontwikkeltraject en bij het doorvoeren van 
wijzigingen te participeren begrensd. RvIG heeft namelijk de dagelijkse zorg voor de huidige BRP- 
voorzieningen en voert daarnaast een aantal projecten uit in het kader van de in beheer name. 
Beide activiteiten vergen inzet van de binnen RvIG beschikbare capaciteit, daarmee is betrekkelijk 
weinig ruimte beschikbaar om daarnaast nog breed in het ontwikkelprogramma te participeren. 
Mogelijk biedt de keuze van de stuurgroep om nieuwe wijzigingen te realiseren in release 1.1 van 
de BRP mogelijkheden om deze wijzigingen mede door medewerkers van RvIG te laten realiseren. 
Dit zal worden bezien na afronding van het lopende ontwikkeltraject. 

Aanbeveling BIT 4 

Bereid de implementatieperiode goed voor en voorkom verrassingen in de planning. 

Activeer RvIG, afnemers en gemeenten bij de voorbereiding van de implementatie: 

a) Vraag RvIG om ten behoeve van de implementatie de acceptatiecriteria van gemeenten en 
afnemers op te stellen. 

b) Laat RvIG instemming vragen van gemeenten en afnemers op deze acceptatiecriteria. 

c) Laat de gemeenten en afnemers een implementatieplanning voor de aansluiting op de BRP 
maken en verwerk deze in de implementatieplanning van het programma. 

d) Sluit in de duale periode de afnemers en gemeenten aan met dezelfde autorisaties als nu 
voor de GBA van toepassing zijn. Sta pas na de duale periode aanvullende autorisaties toe. 

Opvolging van aanbeveling 4: 

Aanbevelingen a) en b) voer ik ten dele uit omdat de formele verantwoordelijkheid voor 
het vaststellen van de acceptatiecriteria niet bij gemeenten en afnemers ligt. 
Aanbeveling c) voer ik uit en aanbeveling d) voer ik uit voor zover dat juridisch mogelijk 
is. 

Toelichting ad a) en b): 

Zoals in de toelichting bij aanbeveling 3 aangegeven vallen de acceptatiecriteria uiteen in 
functionele en niet-functionele eisen. Daarnaast onderken ik functionele acceptatiecriteria ten 
aanzien van de "beheertooling". 

De functionele eisen liggen vast in de wet- en regelgeving, beleidsinterpretaties daarvan en in 
beleidsdocumenten. Deze zijn integraal in kaart gebracht. De detailuitwerking daarvan vindt in 
afstemming met gemeenten en afnemers plaats. RvIG is formeel verantwoordelijk voor het 
vaststellen van de niet-functionele eisen en de acceptatiecriteria voor de "beheertooling". RvIG 
heeft de niet-functionele eisen inmiddels vastgesteld en heeft de stuurgroep daarover 
geïnformeerd. RvIG zal de functionele acceptatiecriteria voor de "beheertooling" op een later 
moment vaststellen. 

Gemeenten en afnemers hebben formeel geen rol in het vaststellen van de acceptatiecriteria. Zij 
zijn via hun vertegenwoordigers wel over de criteria geïnformeerd. Dat geeft hen de mogelijkheid 
eventuele vragen over of opmerkingen ten aanzien van de criteria in de stuurgroep aan de orde te 
stellen. 

Daarnaast maakt RvIG in het Gebruikersoverleg BRP afspraken met afnemers over de prestaties 
van het BRP-stelsel en legt deze vast in een zogenoemd Service Level Agreement (SLA). De 
eerdergenoemde "non functional requirements" die RvIG vaststelt zijn bedoeld om RvIG in staat te 
stellen aan de eisen uit dit SLA te voldoen. 

Toelichting ad cl: 

Het opstellen van de implementatieplanning voor afnemers is in uitvoering. Het programma heeft 
in samenwerking met RvIG in de zomer van 2015 alle afnemers benaderd met de vraag om 
informatie te verschaffen over de contactpersonen voor de realisatie van de aansluiting. Op basis 
van de uitkomst daarvan is het programma gestart met het uitvragen van de aansluitstrategie bij 
de eerste groep afnemers. Bij de vraag naar de aansluitstrategie vraagt het programma tevens om 
een eerste indicatie van het moment van aansluiten, als basis voor de aansluitplanning voor 
afnemers. In de loop van 2016 zal die uitvraag bij alle afnemers plaatsvinden. 

KING zal in 2016 en 2017 vergelijkbare acties als die van het programma uitvoeren waar het gaat 
om aansluitstrategie en aansluitplanning van gemeenten. Waar het gaat om de tijdige aansluiting 
van gemeenten is dit primair de verantwoordelijkheid van VNG en KING. 

Het programma en KING zullen beiden een monitor inrichten om de voortgang bij afnemers 
respectievelijk gemeenten te bewaken. 
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Toelichting ad dl: 

Waar het gaat om het handhaven van bestaande autorisaties bij de overgang naar de BRP geldt 
dat het een juridisch vereiste is om de autorisatiebesluiten van afnemers bij aansluiting op de BRP 
aan te passen, wat zijn basis vindt in de verschillen in de gegevenssets van GBA en BRP. RvIG zal 
afnemers wel ondersteunen bij het verkrijgen van een autorisatie voor de BRP door een concept 
autorisatie op te stellen die is gebaseerd op de huidige (op de GBA gebaseerde) autorisatie van de 
afnemer. De afnemer kan daarbij om een bredere autorisatie vragen (zodat hij ook toegang krijgt 
tot gegevens die wel in de BRP maar niet in de GBA zijn opgenomen). Een dergelijke aanpassing 
zal niet veel complexiteit met zich meebrengen, immers, de autorisatie wijzigt toch al. Door deze 
werkwijze wordt tevens voorkomen dat na de duale periode een tweede maal autorisatiebesluiten 
moeten worden aangepast en de feitelijke implementatie van de BRP (gebruik van de nieuwe 
mogelijkheden) door zou lopen tot na de duale periode. 
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BIJLAGE: Analyse van de door BIT geduide risico's en onzekerheden 

BIT benoemt een vijftal risico's en onzekerheden. Daarop ben ik in mijn eerdere reactie (dd. 23 
oktober 2015) ingegaan. In aanvulling op deze eerdere reactie heb ik hieronder voor de genoemde 
risico's en onzekerheden een aanvullende toelichting opgenomen. 


Wijzigingen hebben grote invloed (risico/onzekerheid A van BIT) 

Nadere toelichting: 

Het BIT stelt terecht dat wijzigingen tijdens de uitvoering van het programma grote gevolgen 
hebben. Dat heeft een aantal oorzaken: 

• een wijziging heeft als direct gevolg dat het ontwikkelproces (ontwerp, bouw, test, acceptatie) 
voor reeds afgeronde en voor onderhanden systeemdelen feitelijk opnieuw moet plaatsvinden; 

• het programma ontwikkelt drie systeemcomponenten, te weten de BRP zelf, de applicatie voor 
de initiële vulling van de data base en de voorzieningen om de BRP data base tijdens de 
transitie te synchroniseren vanuit gemeentelijke GBA-systemen. Wijzigingen werken (bijna) 
altijd door in al deze componenten, waardoor het opnieuw doorlopen van het ontwikkelproces 
voor al deze componenten aan de orde is. Feitelijk leidt een wijziging in de GBA-systemen dus 
tot drie wijzigingen in de BRP; 

• wijzigingen die het patroon van de oplossing doorbreken hebben grote consequenties. Een 
voorbeeld: het verstrekken van gegevens vindt plaats op basis van autorisaties van afnemers, 
daarvoor is een generieke oplossing ontwikkeld. In 2015 is een wijziging aan de orde geweest 
(en afgewezen) die het verstrekken van gegevens tevens afhankelijk maakte van de waarde 
van individuele gegevens van de betrokken persoon zoals die in de BRP zijn opgenomen. Het 
doorvoeren van deze wijziging zou ingrijpende consequenties hebben gehad voor de hiervoor 
bedoelde generieke oplossing; 

• het is niet mogelijk het project (op een aantal specialistische rollen na) qua bezetting verder te 
laten groeien. Dat heeft een tweetal redenen: 

o uitbreiding van capaciteit rond een aantal cruciale functies (zoals architecten) is niet 
mogelijk. Deze cruciale functies leggen de basis voor de ontwikkeling van het systeem, 
zij kunnen een maximaal aantal ontwikkelaars "voeden" met ontwerpen en 
specificaties; 

o er is sprake van technische afhankelijkheden: er kan maar een beperkt aantal mensen 
gelijktijdig met hetzelfde onderwerp en/of met dezelfde code bezig zijn. 

Het gevolg hiervan is dat extra werk leidt tot extra doorlooptijd. 

Huidige maatregelen van de stuurgroep: 

De stuurgroep heeft bij de herstart van het programma in oktober 2013 besloten om "een hek om 
het programma te plaatsen" en geen wijzigingen te accepteren. Met uitzondering van de twee 
eerder benoemde wijzigingen (L03.9 en Buitenlands Persoonsnummer) is de stuurgroep daar ook 
in geslaagd. Inmiddels is overigens sprake van een derde wijziging, de Wet Voorkomen 
Huwelijksdwang. 

De stuurgroep neemt nu twee aanvullende maatregelen (zie ook bij aanbeveling 1): 

• de stuurgroep neemt geen wijzigingen vanuit de omgeving meer in behandeling, maar verwijst 
die naar release 1.1 van de BRP. De ontwikkeling van deze release vindt plaats na afronding 
van het huidige ontwikkeltraject; 

• in geval van wijzigingen die afkomstig zijn vanuit de politiek laat de stuurgroep voor acceptatie 
daarvan een impact analyse opstellen, die inzicht geeft in de consequenties van de wijziging 
voor het budget en de doorlooptijd van het programma. Dat maakt een weging mogelijk tussen 
enerzijds politieke wensen en anderzijds de consequenties voor het programma. De uitkomst 
van die weging bepaalt of de stuurgroep de wijziging daadwerkelijk laat uitvoeren. 


Transparant zijn over onzekerheden in de planning (risico/onzekerheid B van BIT) 

Nadere toelichting: 

Het programma is in oktober 2013 herstart. Daarbij heeft de stuurgroep de keuze gemaakt de 
onzekerheden gedurende de looptijd van het programma op te lossen. Op basis van de analyse van 
Gartner was het beeld dat het ontwikkeltraject in ieder geval tot en met eind 2016 zou duren. Dat 
gaf de stuurgroep voldoende ruimte om deze onzekerheden op te lossen. 


6 



Daarnaast heeft de stuurgroep bewust de focus gelegd op het opleveren van de ICT-voorzieningen. 
Immers, pas na oplevering van die voorzieningen kunnen de activiteiten rond de acceptatie/in 
beheer name en de implementatie pas starten. Die activiteiten zijn dan ook bij de herstart van het 
programma niet uitgewerkt en daarmee onzeker gebleven. 

De stuurgroep heeft er verder nadrukkelijk voor gekozen om, in het licht van de verwachte duur 
van het ontwikkelproject, de planning voor het gehele traject niet bij de start in detail uit te werken 
maar de planning voor het komende jaar (2014 en later 2015) in detail te laten uitwerken en de 
planning voor latere jaren alleen op hoofdlijnen uit te werken. Bij de detailplanning voor een 
gegeven jaar is steeds helder gemaakt waar de onzekerheden zitten, dat is bij de planning voor 
latere jaren (bewust) niet gedaan. 

Huidige maatregelen van de stuurgroep: 

In maart 2015 heeft de stuurgroep opdracht gegeven per eind 2015 een integrale planning op te 
stellen, waarbij naast het ontwikkeltraject ook de acceptatie/in productie name en de transitie in 
meer detail zijn uitgewerkt, inclusief de dan nog bestaande onzekerheden. De stuurgroep heeft in 
het verlengde daarvan opdracht gegeven voor iedere onzekerheid vast te stellen wanneer deze 
opgelost is en dit in de mijlpalenplanning op te nemen (zodat de stuurgroep dit kan bewaken). 
Onderdeel hiervan was het in meer detail uitwerken van de transitie van afnemers en gemeenten 
naar de BRP. 

Daarnaast heeft de stuurgroep in maart 2015 besloten om voor de ontwikkeling van de complexe 
bijhoudingen een zogenoemde "proof of concept" uit te voeren. Het doel daarvan was de complexe 
ontwerpen rond bijhouden in de tijd naar voren te halen, om zo onzekerheden en risico's op dit 
punt zo vroeg mogelijk in de tijd in kaart te brengen. Voor het onderdeel leveringen is een 
vergelijkbare strategie gehanteerd, in die zin dat het programma de functionaliteit voor 
mutatieleveringen (de meest complexe vorm van leveringen, BOP-stap 3.1) als eerste heeft 
ontwikkeld. 

De stuurgroep neemt nu de volgende aanvullende maatregelen (zie ook bij aanbeveling 2): 

• bij de ontwikkeling van bijhoudingsfuncties start het programma met de meest complexe 
bijhoudingen (huwelijk en geregistreerd partnerschap). Daarmee legt het programma de 
breedst mogelijke basis voor de ontwikkeling van de andere (minder complexe) 
bijhoudingsfuncties; 

• de ontwikkeling van de BRP vindt nog steeds plaats volgens het BRP Opleverplan (BOP). De 
BOP-stappen zijn relatief groot, waardoor de ontwikkeling ervan vaak lange tijd in beslag 
neemt. Daarom zal het programma vanaf oktober 2015 werken met driemaandelijkse releases, 
waarbij iedere release een vooraf gedefinieerde functionaliteit realiseert (de werkpakketten 
voor iedere release zijn inmiddels gedefinieerd). Dit maakt het voor de stuurgroep mogelijk om 
(nog) strakker op de voortgang van het programma te sturen. Daarmee komen risico's en 
onzekerheden eerder aan het licht. 

Als laatste maatregel handhaaft de stuurgroep zijn beleid om transparant te zijn over voortgang, 
resultaten en de uitkomsten van toetsen en audits. 
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Complexiteit van delen van het ontwerp (risico/onzekerheid C van BIT) 

Nadere toelichting: 

Het BIT merkt op dat bepaalde delen van het ontwerp, door de complexiteit van wet- en 
regelgeving en door de beleidsinterpretatie daarvan, complex zijn en dat dat invloed heeft op de 
realisatie, de beheersinspanning en toekomstige aanpassingen. 

Mijn analyse is de volgende. Het ontwerp van de BRP is op onderdelen complex is. De oorzaak 
daarvan ligt zoals het BIT ook aangeeft in de wet- en regelgeving. De complexiteit manifesteert 
zich primair in de volgende zaken: 

• het gegevensmodel, waarin niet alleen rekening is gehouden met de actuele gegevens van een 
persoon, maar ook met de (formele en materiële) historie van die gegevens. Daardoor is het 
gegevensmodel meerdimensionaal; 

• de combinatie van autorisatie (bepalen wie welke gegevens van een persoon mag zien) en 
protocollering (vastleggen wie welke gegevens van een persoon wanneer geleverd heeft 
gekregen); 

• identificatie en autorisatie van bijhouders en afnemers (wie wil (namens welke partij) gegevens 
wijzigen en/of opvragen). 

De ontwikkelaars hebben met deze complexiteit te "dealen", het is niet altijd mogelijk gebleken 
simpele oplossingen te ontwerpen voor deze complexe vraagstukken. Het BIT geeft overigens ook 
geen onderbouwing voor hun indruk dat, gegeven de geldende regelgeving, het ontwerp op 
onderdelen wel wat eenvoudiger had gekund. 

Ten aanzien van de beheerbaarheid en de toekomstige aanpasbaarheid van de oplossing zijn twee 
zaken van belang: 

• het ontwerp van de BRP kent ten eerste expliciet gedefinieerde flexibiliteit (bijvoorbeeld ten 
aanzien van de mogelijkheid nieuwe typen adressen van een persoon toe te voegen); 

• de complexiteit (voor bijvoorbeeld het filteren van de gegevens aan de hand van autorisaties) 
is in een beperkt aantal (goed gedefinieerde) generieke onderdelen geconcentreerd, waardoor 
de complexiteit van de overige onderdelen van de BRP beperkt kan blijven. Deze wijze van 
ontwerpen is met het oog op beheer en het aanbrengen van toekomstige wijzigingen naar mijn 
mening zeer verstandig. 

Waar het gaat om het voldoen aan de eisen van de beheerorganisatie verwijs ik naar de opvolging 
van aanbeveling 3 van BIT. 

De stuurgroep ziet de complexiteit van delen van het ontwerp als een gegeven. Deze vindt 
namelijk zijn basis in wet- en regelgeving. De stuurgroep is van mening dat het programma 
gegeven deze situatie de juiste maatregelen heeft genomen. 


Het beheer van de oplossing (risico/onzekerheid D van BIT) 

Nadere toelichting: 

De BRP werkt (zoals BIT ook aangeeft) fundamenteel anders dan de huidige GBA-V. Dat betekent 

dat medewerkers van RvIG kennis moeten opdoen van ontwerp en werking van de BRP, en niet 

alleen van de BRP zelf maar ook van de beheerfunctionaliteiten. 

Hiervoor zijn de volgende (aanvullende) maatregelen voorzien (zie ook bij aanbeveling 3): 

• medewerkers van RvIG participeren in de uitvoering van het acceptatieproces voor de 
opgeleverde releases. Dit acceptatieproces is bedoeld om te toetsen of de opgeleverde 
systeemdelen voldoen aan de functionele eisen en aan de "non functional requirements" 
(NFR's). RvIG heeft de NFR's opgesteld. 

• na acceptatie van de laatste release zal RvIG de productie acceptatie test (PAT) uitvoeren in de 
productieomgeving. Daarin wordt, in aanvulling op de testen die bij oplevering van elke release 
plaatsvinden, het systeem als geheel getoetst aan de NFR's en wordt de productierijpheid 
ervan beproefd. 

• medewerkers van programma en RvIG verzorgen samen het schaduwdraaien van opgeleverde 
delen van de voorzieningen, waarbij de medewerkers van RvIG niet alleen de werking van het 
systeem zelf maar ook en met name de werking van de beheerfunctionaliteiten beproeven. 

Deze aanpak is gebaseerd op "learning by doing", dat is in de gegeven situatie de meest voor de 

hand liggende aanpak. 
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Voorbereiding van de implementatie (risico/onzekerheid E van BIT) 

Nadere toelichting: 

In september 2015 heeft de stuurgroep de nadere uitwerking van de transitieperiode besproken. 
Die periode kent drie fasen: 

• initieel vullen van de BRP en starten met synchronisatie (aan de hand van mutaties uit de GBA- 
systemen van gemeenten); 

• aansluiten van koplopers afnemers en gemeenten; 

• aansluiten overige afnemers en gemeenten. 

Voor de eerste fase is het beeld dat deze zes weken duurt. Daarin sluiten alle afnemers en 
gemeenten op de GBA-koppelvlakken van de BRP aan. Daarna vindt aansluiting van de eerste 
koploper afnemers plaats. Voor de aansluiting van alle koploper afnemers is zes maanden 
uitgetrokken. Op die manier is ruimte beschikbaar voor het oplossen van kinderziekten. Na deze 
periode sluiten alle andere afnemers aan. Als de eerder bedoelde kinderziekten zich niet voordoen 
zal aansluiting van de koploper afnemers minder dan zes maanden vergen. 

Twee maanden na de aansluiting van de eerste koploper afnemer sluit de eerste koploper 
gemeenten aan. Voor de aansluiting van alle koplopers gemeenten is eveneens zes maanden 
uitgetrokken. Daarna sluiten alle gemeenten aan. Als de eerder bedoelde kinderziekten zich niet 
voordoen zal aansluiting van de koploper gemeenten minder dan zes maanden vergen. 

Op basis van gesprekken met leveranciers van burgerzakenmodules, die een belangrijk deel van de 
aansluiting voor hun rekening nemen, is het beeld dat het mogelijk de gehele transitie binnen de 
gestelde twee jaar af te ronden. Een vergelijkbaar beeld komt naar voren uit afstemming met een 
grote leverancier van afnemersystemen. 

Zowel leveranciers als RvIG geven aan dat zij de planning voor het aansluiten van een individuele 
afnemer of gemeente bij het aansluiten van de koplopers zullen valideren. Op basis daarvan zullen 
zij vaststellen of de vigerende planning realistisch is. 

Waar het gaat om de voorbereiding op de transitie en de duur van de implementatieperiode is van 
belang dat die mede bepaald wordt door het tempo waarin leveranciers van burgerzakenmodules 
en afnemersystemen hun klanten kunnen voorbereiden en daadwerkelijk kunnen aansluiten op de 
nieuwe voorzieningen. De mogelijkheden voor het programma om hier invloed op uit te oefenen 
zijn beperkt. 


9 



